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I. Background and Motivation 


In the early 1980s, video arcade games were ever-present in the minds of children, teenagers, and 
adults alike. As early as the year 1980, 86 percent of the US population between 13 and 20 had at least 
played a video arcade game [1]. This rapid expansion of interest in video games led many teenagers and 
young adults to shift away from traditional sports as a competitive outlet, and over to dedicating their free 
time to mastering these new forms of digital entertainment. 

Beginning in 1980, large-scale video game tournaments began to be held, with one of the first 
being the Space Invaders Championship, hosted by Atari [2]. From here, organizations and teams were 
founded for the proliferation of interest into the playing of arcade games at a competitive level. One of 
these was Twin Galaxies, which was founded by Walter Day in 1981 in Ottumwa, Iowa [3]. Walter Day’s 
iteration of Twin Galaxies allowed players to compete head-to-head for a chance at getting their high 
score achievements recognized in the Guinness Book of World Records. This was a seminal moment for 
the beginning of eSports, which has grown far larger than what could have ever been imagined in the 
early 80’s [4]. 

Almost 40 years on from this point, new generations of players have picked up the hobby of what 
is now called “Classic Arcade Gaming”. As was done in the past, players today still compete 
head-to-head through online tournaments for notoriety in the community. However, instead of 
tournaments being exclusively held in-person on now-vintage arcade machines, many players choose to 
use an emulator called MAME to play these games. Some sites, such as DonkeyKongForum.net, choose 
to compile MAME and arcade scores into a single scoreboard. Others, like the modern Twin Galaxies, 
separate MAME and arcade scores into two different scoreboards. Regardless, whether these scores are 
separated or intermingled, the platform that the score was achieved on is specified [5]. 

Prior to the last 20 years, scores were not often recorded in full (digitally or on VHS). Before 
these times, scores had to be verified by a referee, or simply through a photograph of the score on the 
screen [6]. With these older scores, it is unlikely that there is any question whether the score was achieved 


on arcade or emulator, due to the MAME emulator not being well-developed until about 2000 [7]. 
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However, after MAME came to a sufficient point of maturity, a problem arose: a MAME recording could 
be passed off as a “direct-feed” arcade recording. A direct-feed arcade recording is one where the video 
output of the arcade machine motherboard is directly sent to a video capture device, in contrast to simply 
pointing a camera at the monitor. Figure 1 below shows a comparison between the video output of 
direct-feed arcade versus a screen capture of MAME (from a modern computer) from the arcade game 


Donkey Kong, demonstrating how similar the images look. 


Direct Feed Arcade Gameplay MAME Gameplay 
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Figure 1: Video from a Donkey Kong arcade machine (left) compared to MAME output (right). 

As mentioned, legitimately recognized scores are set on both the MAME and arcade platforms. If 

this is the case, one may think that there is little issue with passing off a MAME score as arcade. 

However, as will be explained in detail below, this assumption would greatly put the integrity of the 


scoreboard at risk of showing falsified scores. 


When a MAME score is submitted to the Donkey Kong Forum or Twin Galaxies scoreboards, the 
most important evidence for the submission is the MAME input file, also known as an “INP” file. This 
digital file, which records the player’s inputs, allows for a score to be played back on the MAME 
emulator, showing the gameplay that the player executed during their performance. One important 
distinction with officially recognized INP files is that they must originate from a special version of 
MAME known as WolfMAME. In the non-WolfMAME version of MAME, it is easy to create a 
spliced-together INP file that would not show any obvious signs of tampering when the file is evaluated 
for legitimacy on the MAME emulator. Thus, for competitive submissions, it is required that WolfMAME 
be used [8]. In WolfMAME, cheats are removed, the use of savestates for splicing INP files is removed, 
and the game settings, which are controlled by dual in-line package (DIP) switches on a real arcade 
machine, are fixed to a set value [9]. 

Even with all these precautions, some people have still managed to create spliced-together input 
files. In 2016, a player named Jose Ramis was permanently banned from the scoreboards for MAME 
Action Replay (MARP) and Twin Galaxies for using virtual machine software to create a seamless INP 
file that would play back in WolfMAME [10]. Ultimately, his attempts at cheating failed due to the strong 
analysis methods employed by MARP referees for detecting cheating in WolfMAME INP files. It is 
important to note that the cheating methods used by Jose Ramis were only detected due to the presence of 


an INP file. The playback speed variation from his Galaga submission is shown in Figure 2. 


"PAC" - Galaga (Namco rev. B) - 20,000,000 - WolfMAME 0.162 
romset: galaga 


INP Start Time: 2015-08-07 19:55:01 UTC 

Number of Frames: 2,530,041 Maximum Recorded Speed: 157.037449% 
Estimated Elapsed Time: 11:37:53.242 Minimum Recorded Speed: 10.569286% 
Estimated INP End Time: 2015-08-08 07:32:54 UTC Filename: galaga.inp Average Recorded Speed: 99.695352% 
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Figure 2: INP splicing through a virtual machine, which manifests as playback speed variation. Each 
spike represents a pause or replay at that frame. 

If the playback of this cheated INP file was recorded by video capture software and subsequently 
passed off as arcade, there would be no way of knowing the methods that were used to cheat. Only INP 
file analysis could have revealed the playback speed variation. Demonstrably, it is very important to 
ensure that an arcade performance has been played on real arcade hardware, where splicing (outside of 
obvious video editing), is not possible. 

For both direct-feed and camera recordings of the arcade gameplay, a board and control panel 
verification is required by Donkey Kong Forum and Twin Galaxies [11]. In this verification, the arcade 
hardware (motherboard and underside of the control panel) is shown to verify that the hardware is 
untampered with. For many games, these types of rules are recent. Higher scrutiny in arcade Donkey 
Kong scores only came after about 2008 [12]. Before this, hardware verification was not a required step 
for the submission to Guinness or Twin Galaxies. Due to this fact, there are some scores before this date 


that were performed when MAME existed, and hardware verification was not a required step. 


For these certain scores, such as Billy Mitchell’s contested 1,047,200 and 1,050,200 tapes, video 
evidence is all that exists for examining if a score was truly performed on arcade hardware. In this 
document, arcade Donkey Kong is analyzed for the differences between MAME and arcade gameplay. 
Additionally, these findings are applied to Billy Mitchell’s scores in the second part of the paper to 
evaluate them for MAME signatures. It is imperative to recognize the differences in video rendering 
between these two platforms to prevent illegitimate achievements from being accepted on a scoreboard, 


hurting the credibility of the scoreboard and its controlling organization. 


II. Orientation and 240p video Explanation 
Ia. Brief CRT (Cathode Ray Tube) Explanation 

Even though the video signal from an arcade machine can be captured and displayed on any 
monitor or computer today, the original video signal was designed with CRT monitors in mind. CRT 
monitors were the technology used in every television prior to the advent of flat screen technology. It is 
important to understand how CRT monitors operate before grasping how RGB video signals are output by 
arcade machine boards. 

In vintage arcade monitors, three electron beams (negative charges) are generated at the back of 
the tube by a heated cathode. These electron beams are then attracted at high velocities to the front of the 
monitor due to the anode, which contains a large positive charge (usually 10,000+ volts) [13]. Left 
unabated, these beams collide with the phosphor layer, which illuminates when struck with charges at the 
front of the CRT and makes a bright white dot at the center of the monitor. However, the motion of these 
electrons is influenced by nearby magnetic fields, allowing dots to appear anywhere on the screen. In 
technical terms, the deflection force on the beam is given by the cross-product of the beam velocity and 
the magnetic field strength, which is defined by the Lorentz Force equation: 

F = qv x B, 


where q is charge, v is charge velocity, and B is the magnetic field strength 


Utilizing this principle, vintage arcade monitors include a large coil, or “yoke”, that is used for 
deflecting the electron beam. The yoke is used to steer the electron beam as it scans across the screen, 
drawing the image. The input video signal to the monitor is processed to deflect, “slow down”, and 
“speed up” this beam as it scans across the screen. This modulation of the speed of the electrons 
impacting the screen is controlled by the control grids within the monitor tube. The “slowing down” and 
“speeding up” of the electron beam manipulates the brightness at the location of each phosphor on the 


front of the monitor tube by adjusting the velocity that the beam impacts the phosphors. 


IIb. RGB Video Explanation 


Most arcade machines, including Donkey Kong, utilize raster monitors. Raster monitors use four 
different signals to represent the video signal on the screen. These four signals are red, blue, and green 


color signals, as well as a sync signal. These signals are shown in Figure 3: 
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Figure 3: Red, blue, and green (positive values) and sync waveforms (negative values). 

First, the purpose of sync must be understood. From [13], even when there is no input video 
signal or image to the monitor, the deflection coil constantly scans the electron beams for red, green, and 
blue left to right, line-by-line, until the bottom of the screen is reached. At this point, the beam repeats the 
scanning process. To know when the start of each frame is, the video signal contains two distinct pulses of 
a well-defined width and spacing in the time domain: a horizontal sync pulse and a vertical sync pulse. 
For Donkey Kong’s progressive scan video, the total resolution contains 264 horizontal lines, but only 
224 of these lines display game graphics [14]. Additionally, the vertical refresh rate is 60.60606 Hz for 
Donkey Kong [15], which designates how many times per second that the beam scans from the top to the 


bottom of the screen. 


For the monitor to lock on to the incoming video signal, it must catch these horizontal and 
vertical sync pulses, so the video begins displaying at the start of when the beam begins scanning again at 
the top of the monitor. Without this timing, if the input video were to be sent out of sync with where the 
beam is scanning, the resulting video on the screen would be jumbled and it would never recover. 

The important takeaway from this section is that the Donkey Kong PCB is always scanning in 
video left-to-right, and then down a line at the conclusion of each line’s scanning process. This video will 
be interpreted the same whether the output device is a CRT monitor or digital capture device. Figure 4 is a 
visualization of this scanning process. In Figure 5, the scanning can be seen on an actual monitor using a 
high-speed camera. 
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Figure 4: The scanning of the beam across the monitor, and the corresponding sync pulses (with the 


monitor in a horizontal orientation). 


Figure 5: The scanning of the beam across a monitor for a single frame, recorded using a high-speed 


camera [16]. 
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IIc. Orientation 


Due to this scanning mechanism and RGB video standard itself, the output video from a 240p 


arcade game will always draw in the same orientation, assuming the input video hardware and software 
are unmodified, and the screen data is read in the same order from memory. This observation is significant 
for Donkey Kong gameplay footage in that it is a clear marker for edited gameplay or gameplay that is 
generated on modified hardware. Notably, MAME did not correct for its wrong image orientation until 
version 0.196 in 2018 [17], so all versions prior to that leave this marker in the recording. 


Video from an unmodified Donkey Kong arcade machine board displays as shown in the left side 
of Figure 6. The television is sideways because Donkey Kong’s monitor is positioned in a vertical 
orientation in the arcade cabinet. When compared to output from non-original hardware or an edited video 


tape (such as Billy Mitchell’s 1,047,200, also shown in Figure 6), the difference is clear. 


Raw output from direct feed to TV Billy Mitchell 1,047,200 to TV 
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Figure 6: The unedited output from a Donkey Kong board to an external video monitor in a vertical 
orientation. Video is converted from 15 kHz RGB to composite video using a AD725 encoder (non-digital 
process) compared to Billy Mitchell’s 1,047,200 Tape Footage from the 2007 documentary film “King of 


Kong”. The “bottom” of the screen is reversed from what is seen in the unedited video output. 
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The visible difference between the video outputs in Figure 6 clearly demonstrates a discrepancy 
between the video hardware in these two capture setups. As mentioned in the first section, the order the 
video data is scanned into the output video device does not change without changing the order of the data 
that is leaving the arcade board. Two analog CRT monitors are the most effective way to demonstrate this 
point to avoid any confusion that results from digital capture solutions. 

In Donkey Kong, there are ways to flip the monitor orientation through the game itself. One 
example that would be known to someone who has played a cocktail cabinet. In figure 7, a two-player 


game being played in cocktail mode is shown. 


Figure 7: Donkey Kong cocktail cabinet. Controls are on either side of the monitor for two players to 
switch off playing. 

However, this kind of argument for an incorrect orientation can quickly be debunked. Arcade 
games such as these include a series of DIP switches to control various game factors, such as the cost to 
play and the number of lives given [18]. For the game to display in cocktail mode, these dip switches 
must have switch H set to off [19]. This issue would easily be spotted in the game verification, and 
certainly would be identified by any experienced individuals onsite to verify the legitimacy of a game. 

Additionally, the orientation is only flipped when player two is playing the game, to the other side 


of the table shown in figure 7. This problem would immediately be observed due to the presence of the 
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second player’s score on the screen being the score in-play. This issue is not observed in the gameplay in 


Figure 6, which indicates a deeper issue as to why the orientation is different. 


HII. Donkey Kong Arcade Hardware Transitions 


In this section, the concept of transitions between screens and how they are composed on arcade 
Donkey Kong is introduced. The information described in this section is essential for identifying whether 


suspect gameplay created on an emulation platform has been passed off fraudulently as real arcade 


hardware. These transitions are like a fingerprint of the platform the game was played on. 


IIIa. Arcade Donkey Kong Transition Definition 


Before explaining the transition mechanism and expected video output, the definition of the 
transition itself must first be understood. Donkey Kong includes four types of stages, each with a unique 
transition. However, the barrel transition is sufficient to examine for evidence of non-arcade hardware. 

In figure 8, the How High Can You Get? screen is seen. This is the image that is displayed right 


before the graphics are drawn that make up the barrel stage. 
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Figure 8: One example of the How High Can You Get? screen that appears before the start of the 


transition. 
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Next, the process of the transition drawing begins. In a total of three frames, all the girders and 
ladders are drawn onto the screen. These three frames for arcade hardware are shown below in Figure 9. 


Notably, these images are at the end of each frame during the transition drawing cycle. 


End of Frame 1 End of Frame 2 End of Frame 3 
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Figure 9: The three transition frames in which all ladders and girders are drawn onto the screen 


(captured from real arcade hardware). 


IIb. How Transitions are Drawn on Donkey Kong Hardware 


On original Donkey Kong hardware, the central processing unit (CPU) and video circuitry are 
separated into two boards: the CPU board and the video board. The CPU board, which contains the Z80 
CPU, controls functions such as how the score is kept, what level the game is on, and the number of lives. 
All the game logic is stored on erasable programmable read-only memory (EPROMS) and written in Z80 
assembly language. Additionally, the board contains random access memory (RAM) that stores ephemeral 
data, like a character’s position or the player’s current score. 

The video board also contains EPROMs, but the data contained in them is different from the CPU 
board. For instance, the sprite ROMs on the board contains information about how the fireballs or 


Jumpman will look on the screen. In Figure 10, the Donkey Kong PCB board stack is seen. 
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Figure 10: Donkey Kong arcade boardstack, where the video board is on the left, and the CPU board is 
on the right. These boards are connected together by the ribbon cables at the bottom. 
In the next few paragraphs, the ROM disassembly for Donkey Kong is referenced for insight on 
how graphics are filled into VRAM [20]. When it is time for the barrel stage to be drawn on the screen, 
the game code instructs the Z80 to load the DE register (data saved within the CPU) with the address 


#3AE4, which is a location in the CPU ROM that designates the start of the girder drawing data table. 


This is shown in Figure 11. 


OcD4 11E43A LD DE , #3AE4 ; Load DE with start of table data for girders 
OCD7 3E08 LD A, #08 ; A := 8 = music code for girders 

OCD9 328960 LD (#6089) ,A ; set music for girders 

OcDC C3C60C JP #0CC6 ; jump back 


Figure 11: First code block sor the beginning of the girder drawing. 

Next, the code at #0CDC jumps to another location that ends up at the start of the girder drawing 
routine. There are additional routines for ladder drawing, but we’ll focus on the girder routines. The code 
block in Figure 11 executes repeatedly to populate register HL with the location in video RAM (VRAM) 
where the girder drawing data table from the ROM will be written to. This subroutine is shown in Figure 


12. 
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ODA7 1A LD A, (DE) ; load a with DE - points to start of table data 
ODA8 32B363 LD (#63B3),A ; save for later use 

ODAB FEAA CP #AA ; is this the end of the data? 

ODAD C8 RET Z ; yes, return 


ODAE 13 INC DE ; next table entry 

ODAF 1A LD A, (DE) ; load A with table data 

ODBO 67 LD H,A ; copy to H 

ODB1 44 LD B H ; copy to B 

0DB2 13 INC DE ; next table entry 

ODB3 1A LD A, (DE) ; load A with table data 

ODB4 6F LD L,A ; copy to L 

ODB5 4D LD Cre mucopy toC 

ODB6 D5 PUSH DE ; save DE 

ODB7 CDF02F CALL #2FFO ; convert HL into VRAM address 

ODBA D1 POP DE ; restore DE 

ODBB 22AB63 LD (#63AB) ,HL ; store the VRAM address into this location for later use. 
ODBE 78 LD A,B ; A := B = original data item 

ODBF E607 AND #07 ; Mask bits, now between 0 and 7 

ODC1 32B463 LD (#63B4) ,A ; store into temporary storage for Vram x/y coords 
opc4 79 LD A,C ; A := C = 2nd data item 

ODC5 E607 AND #07 ; mask bits, now between 0 and 7 

ODC7 32AF63 LD (#63AF) ,A ; store into temporary storage for Vram x/y coords 
ODCA 13 INC DE ; next table entry 

ODCB 1A LD A, (DE) ; load A with table data 

ODCC 67 LD H,A ; copy to H 

ODCD 90 SUB B ; subtract the original data. less than zero? 
ODCE D2D30D JP NC, #0DD3 ; no, skip next step 

ODD1 ED44 NEG ; Negate A (A := #FF - A) 

ODD3 32B163 LD (#63B1) ,A ; store into temporary storage for Vram x/y coords 
ODD6 13 INC DE ; next table entry 

ODD7 1A LD A, (DE) ; load A with table data 

ODD8 6F LD L,A ; copy to L 

ODDS 97 SUB c ; subtract the 2nd data item 

ODDA 32B263 LD (#63B2),A ; store into temporary storage for Vram x/y coords 
ODDD 1A LD A, (DE) ; load A with same table data 

ODDE E607 AND #07 ; Mask bits, now between 0 and 7 

ODEO 32B063 LD (#63B0) ,A ; store into temporary storage for Vram x/y coords 
ODE3 D5 PUSH DE ; save DE 

ODE4 CDFO2F CALL #2FFO ; convert HL into VRAM address 

ODE7 D1 POP DE ; restore DE 

ODE8 22AD63 LD (#63AD) ,HL ; store into temporary storage for Vram x/y coords 
ODEB 3AB363 LD A, (#63B3) ; load A with first data item 

ODEE FE02 CP #02 ; < 2 ? are we drawing a ladder or a broken ladder? 
ODFO F24F0E JP P, #0E4F ; no, skip ahead 


Figure 12: Subroutine for filling VRAM with the data for the table data from the ROM. 
The subroutine starts by loading register A with register DE, which was loaded with the memory 
location at the start of the table. Throughout the subroutine, the value of DE is incremented, which acts as 
a pointer that is used to load the next element of the girder drawing instructions from the ROM into 


VRAM. Line #0DB7 jumps to a routine which converts HL to the VRAM address where the girder data 


will be drawn. Additionally, the table data itself is constantly being passed off from registers A and DE 
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into RAM locations like #6350, due to the Z80 processor’s limited registers. The table data located at 


#3AE4 for the girder stage is seen below in Figure 13. 


3AE4: 
3AEQ9: 
3AED: 
3AF3: 
3AF8: 
3AFD: 
3B02: 
3B07: 
3B0C: 
3B11: 
3B16: 
3B1B: 
3B20: 
3B25: 
3B2A: 
3B2F: 
3B34: 
3B39: 
3B3E: 
3B43: 
3B48: 
3B4D: 
3B52:: 
3B57: 
3B5C: 


02 
02 
02 
02 
02 
02 
02 
02 
02 
00 
00 
00 
00 
ou 
00 
00 
00 
01 
00 
00 
00 
00 
01 
01 
AA 


97 
oF 
DF 
EF 
DF 
EF 
DF 
FF 
TF 
CB 
CB 
CB 
63 
63 
33 
B83 
53 
53 
5B 
73 
83 
93 
BB 
6B 


38 
54 
58 
6D 
9A 
AF 
DC 
FO 
F8 
57 
99 
DB 


68 
10 
AO 
20 
10 
20 
10 
80 
00 
CB 
CB 
CB 
63 
63 
33 
33 
53 
53 
5B 
73 
83 
93 
BB 
6B 


38 
54 
55 
79 
8E 
BB 
DO 
F7 
F8 
6F 
B1 
F3 
54 
F8 
90 
D2 
54 
B8 
92 
D6 
B5 
54 
98 
75 


top girder where girl sits 


; girder where kong sits 


lst slanted girder at top right 

2nd slanted girder (has hammer at left side) 
3rd slanted girder 

4th slanted girder 

5th slanted girder (has hammer at right side) 


; bottom slanted girder 
; bottom flat girder where mario starts 


short ladder at top right 
short ladder at center right 
short ladder at bottom right 


; kong's ladder (right) 
; bottom broken ladder 


short ladder at left side under top hammer 
short ladder at left side above oil can 


; kong's ladder (left) 


second broken ladder from bottom, on 3rd girder 
longer ladder under the top left hammer 

longer ladder to left of bottom hammer 

center longer ladder 

ladder leading to girl 

third broken ladder on right side near top 
fourth broken ladder near kong 


; AA code signals end of data 


Figure 13: Data from the ROM for instructions on how to draw the girder stage. Numbers shown in 


hexadecimal. 


These drawing instructions reveal in what order the VRAM is filled up, as the subroutine in 


Figure 12 points to each VRAM location. Of the five hexadecimal bytes in each line, the first represents 


the object type. (06 is a given character, 05 is the girder style used on the game's “rivet” screen, 03 is a 


conveyor, 02 is a girder as seen on the “barrel” screen, 01 is a broken ladder, and 00 is a complete ladder. 


Note that since Figure 13 represents the game drawing the barrel board, only objects 00, 01, and 02 are 


seen.) Bytes 2 and 3 give the X/Y location for the start of the drawing, and bytes 4 and 5 give the ending 


X/Y location for the drawing. Thus, seeing this data sequentially, it is concretely known what order the 


VRAM fills up with data. This is important for modeling this behavior. 


Finally, after a location in CPU RAM has been filled with the value of the table, this value can 


finally be written to the location of VRAM that was stored in HL. This code is seen in Figure 14. 
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0E62 3AB563 LD A, (#63B5) 
OE65 77 LD (HL) ,A 
OE66 23 INC HL : 


Figure 14: RAM location is loaded into A, A is loaded into EE at HL ET is a location in VRAM, 
loaded during the subroutine at #63AB). HL is incremented and the process repeats. 

However, this video memory does not fill up with the newly drawn frame instantly. Due to the 
CPU having to run through this loop of filling up the video memory byte by byte, it takes multiple frames 
for the VRAM to populate. Most importantly, the CPU and video hardware cannot access the memory at 
the same time, so the CPU must execute all writing functionality to the VRAM during the time of the H 
blank, which occurs at the time of the H sync pulse shown in Figure 4. In Donkey Kong hardware, video 
hardware is given VRAM priority by default for access. Regular CPU RAM and ROM don’t have these 
restrictions, so other tasks are able to execute in the meantime between scanlines. As a result, the H sync 
pulse acts as an interrupt of sorts where the CPU can run through a loop of the VRAM filling during the 
video blanking period. In essence, the CPU waits around for the video hardware to finish accessing the 
VRAM before it can write girder data to VRAM. 

To demonstrate how the filling of the VRAM and RAM scanning mechanism interact together to 
create the arcade hardware transitions, a helpful animated GIF is provided. In Figure 15, the progression 
of the scanning bar (seen as a pink bar, scanning left to right) is seen in relation to the contents of the 
arcade VRAM, seen on the left. The bar is also scanning from bottom to top during each scanline, but 
this process is occurring very quickly. As the pink bar scans, the VRAM contents are filled with the data 


from the video ROM. To the right of the VRAM, the output on the screen is seen from this process. 
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Figure 15: Filling of VRAM in relation to the scanning process, versus the arcade output (generated using 
a custom ROM on MAME that mimics arcade rendering behavior). 

From this figure, all the transitions in Figure 9 can be identified at the point at which the pink bar 
reached the end of the screen. Additionally, the order in which VRAM is populated has been verified 
through the code itself, and the scanning mechanism’s root cause has been identified through the known 
mechanism of how raster video is generated. It can be understood that anything that is in VRAM at any 


given time is available for the video hardware to scan it onto the screen at the refresh rate timings. 


Additionally, it is very pertinent to say that any variation from this scanning/filling of VRAM on 


arcade hardware requires software or hardware modification. From Figure 15, only two factors are 


relevant to the drawing of transitions, which is the rate VRAM is filled and the rate the video hardware 
scans the memory for changes. Changes to this scanning mechanism are infeasible without massive 
hardware modifications, as no vintage monitor would ever tolerate the timing changes in the scanning 
process. For instance, the Sanyo monitor in the Donkey Kong machine will tolerate 500 Hz of variation 
from the horizontal sync frequency of 15.75 kHz, and 5 Hz of variation from the vertical sync frequency 


of 60 Hz before desyncing [21]. For the player, such large changes would manifest in what would look 
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like random or un-synced output on the screen, due to RGB color data being misplaced on the screen from 
lack of sync. The kind of changes required, like adding a framebuffer to the video hardware, could never 
result from aging or failing components. For the VRAM contents, the drawing order is clearly given in 


Figure 13. The only way for the transitions to change from a software sense would be to change this data 


order. This process requires modification of the game ROMs, which violates competitive rules. 


IV. MAME 0.115 and Below Donkey Kong Transitions 


To spot the difference between legitimate transitions from arcade hardware and those from 
non-arcade hardware, it is important to understand the transitions from MAME, which is the most used 
software for emulating Donkey Kong. 

MAME, which was first developed in 1997, is a hardware emulator that emulates thousands of 
different games by representing the physical components and integrated circuits (ICs) as a computer 
program. In MAME, the ROMs that are present on a real arcade machine have been “dumped”, which is 
the process of reading the contents of the original chips and copying them to binary computer files that 
the emulator can interact with. Therefore, all software behavior that was described in the previous section 
still holds true for MAME. 

However, as mentioned, MAME is a hardware emulator. Hardware emulation approximates the 
original system, and many chips on old computers and arcade boards are not well documented [22]. The 
early development of MAME simulated, by closest approximation, the behavior of the target hardware, 
rather than the physical transistor connections (hardware accuracy) within the individual ICs themselves, 
or how long the execution of each instruction should take (cycle accuracy). 

To understand the scanning of the VRAM in MAME, the source code can be directly referenced 
for MAME 0.115, which is the version before MAME updated the refresh rate to 60.6 Hz from 60 Hz 
[23]. For MAME, all machines are dictated by the common MAME video and CPU drivers. This can be 
thought of as the engine for MAME. In tilemap.c, the procedure for writing VRAM to the tilemap is 


described. This is shown in Figure 16. 
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Figure 16: Description of how the tilemap is updated in MAME. 
The tilemap in MAME is generally used for updating non-sprite graphics. In Donkey Kong, sprite 


drawing is handled by the draw sprite function, which is unrelated to the transitions. Figure 17 


describes that the VRAM is constantly being scanned for changes at a rate much faster than the game 
CPU clock. In fact, once a change appears in VRAM, it instantly appears in the tilemap by being marked 
as “dirty”, or in need of being updated. From here, examination of the file video/dkong.c shows how the 
video driver for Donkey Kong is handled, with the procedure in Figure 16 in mind. In Figure 17, the write 


handler for VRAM is shown from video/dkong.c. 


WRITE8 HANDLER( dkong_videoram w ) 
{ 
if (videoram[offset] != data) 
{ 
videoram[offset] = data; 
tilemap_mark_tile dirty(bg tilemap, offset); 
} 
} 


Figure 17: Write handler for VRAM to tilemap in the dkong video driver. 

In this function (which is part of one of the macros in MAME), an if statement checks if the 
stored VRAM at a certain offset has a different value than the incoming data. If this is the case, the 
VRAM is set to this new data value, and the tile that corresponds to this VRAM offset is set as dirty (in 
need of being updated). In the next part of the video driver, after the video has been fully initialized, the 


entire tilemap is drawn at once. This code is seen in Figure 18. 


VIDEO_UPDATE( dkong ) 


{ 
tilemap_draw(bitmap, cliprect, bg tilemap, 0, 0); 
draw_sprites (bitmap, 0x40, 1); 
return 0; 


Figure 18: Update function for Donkey Kong video. 
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This VIDEO UPDATE function is called once per frame, or 1/60 seconds in MAME 0.115. 


Therefore, since the tilemap is constantly filled with the latest updated VRAM at the frame update time, it 
is obvious that the scanning behavior that is seen in arcade Donkey Kong is simply not present in MAME. 
The scanning was replaced by an instantaneous snapshot of the VRAM state. 

From this analysis, you can see that MAME 0.115 utilizes a framebuffer mechanism for the 
scanning of the VRAM. This kind of scanning behavior is acceptable for MAME as the program does not 
need to match the refresh rate of the user’s monitor. The MAME window is rendered within a window on 
the player’s computer, which is likely to not be running at 60 Hz at all. 

This behavior can be seen in the animations below in Figure 19, which demonstrate the video 
output of MAME versus the VRAM content and framebuffer, as well as the previously shown arcade 
VRAM scanning mechanism. 


000000 007650 000000 007650 


Arcade vram Arcade output 


900000 007650 000000 007650 


MAME vram MAME output 


Figure 19: Filling of VRAM in relation to the framebuffer, versus the MAME output (generated using a 
custom ROM on MAME that mimics MAME 0.115 rendering behavior) in the bottom half, versus Filling 
of VRAM in relation to the scanning process, versus the arcade output (generated using a custom ROM on 


MAME that mimics arcade rendering behavior) in the top half. 
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Just as with the arcade animations, the flashing pink screen represents the reading of VRAM (as 


seen on the left) to the screen (as seen on the right). As mentioned, and shown in the MAME source code 


this process happens instantaneously, which is impossible on arcade hardware due to the monitor 
requiring sequential, scanned-in video. From this analysis, there are obvious differences between the 


transitions of MAME and arcade. In section V, these differences are examined in depth. 


V. MAME versus Arcade Transition Comparison 


For this section, arcade and MAME transitions are compared directly to better visualize the 
differences. Below in Figure 20, the first rendered transition frame is shown for MAME 0.115 next to a 


frame from unmodified arcade hardware. 


MAME 0.115 Frame 1 Arcade Frame 1 
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Figure 20: MAME 0.115 frame 1 (left) transition versus arcade frame 1 (right) transition. 


The difference between these two frames is overtly clear. In the example on the left, three girders 


are rendered by the end of the first frame, whereas in the example on the right, the first frame shows five 
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girders are rendered along the right side. This behavior was predicted and documented from the analysis 
of the MAME source code in the previous section, as well as the analysis of the Donkey Kong source 
code VRAM writing process. In the example on the right, five girders are drawn by the end of the first 
frame. Since the arcade has no framebuffer, these differences are expected. It is impossible for arcade 
transitions to look like the frame on the left without software or hardware modification. 

Using the information analyzed in this paper, games that have been suspected of not being played 
on unmodified hardware can be compared to both MAME and arcade transitions. One heavily scrutinized 
game of this kind is Billy Mitchell’s 1,050,200 score from 2007. Prior to MAME 0.116, MAME’s 
rendering of Donkey Kong transitions had been consistent since 2001. Thus, MAME 0.115 is used for the 
following tests. In Figure 21, the comparison between MAME, Arcade, and Billy Mitchell’s 1,050,200 


tape is seen. 


Billy Mitchell 1,050,200 Frame 1 MAME 0.115 Frame 1 Arcade Frame 1 
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Figure 21: Mitchell’s 1,050,200 (left) versus MAME (middle) versus arcade (right). 


From this image, the first frame of the transitions in Billy Mitchell’s tape visually does not match 
the arcade transitions. However, MAME 0.115 and Mitchell’s tape have a small, but important difference. 
At the end of the girder on the two tapes, there is a partially drawn girder that is entirely drawn on MAME 


0.115. This variation may seem small, but it is significant. In versions of MAME past 0.115, this partially 
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drawn girder can be seen. However, these versions of MAME did not exist when Mitchell’s 1,047,200 
was made, and 0.116 was released just one month before the 1,050,200 tape. 

In MAME 0.116u3, the vsync frequency of Donkey Kong hardware was changed to 60.606061 
Hz [24], as this is more accurate to the real arcade machine. However, prior versions of MAME ran 
Donkey Kong at 60 Hz. Therefore, by using the MAME option to change the refresh rate on the older 
MAME version to 60.6 Hz, the partially drawn girder was visible. Alternatively, the CPU speed can also 
be set to 99% through cheats, which accomplishes the same effect. Figure 22 shows this setting in the user 
interface (UI) of MAME, and Figure 23 shows the comparison of the transitions again using the adjusted 


refresh rate (along with a frame from Mitchell's 1,047,200 tape). 
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Figure 22: Refresh rate set to 60.6 Hz in MAME. 


Billy Mitchell 1,047,200 Frame 1 Billy Mitchell 1,050,200 Frame 1 MAME 0.115, 60.6 Hz Frame 1 Arcade Frame 1 
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Figure 23: Mitchell's 1,047,200 (1st) versus Mitchell’s 1,050,200 (2nd) versus MAME 0.115 w/ 60.6 Hz 


refresh (3rd) versus arcade (4th). 
In the figure above, Mitchell’s tapes and MAME 0.115 with a 60.6 Hz refresh rate are identical. 
From this analysis, it is proven that Mitchell’s 1.047.200 and 1,050,200 tapes were generated using a 


version of MAME’s source code from 2001 to 2007 with the refresh rate set to 60.6 Hz. It is demonstrably 
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impossible for unmodified hardware to show the first, second, and third transitions in Figure 23. Only the 


five-girder pattern shows for unmodified hardware. 


VI. Discussion and Conclusion 


From the above technical analysis, unmodified Donkey Kong arcade hardware cannot produce the 
three-girder pattern in the first frame of the barrel transition. Not only this, but it is also evident that the 


transition acts as a fingerprint that indicates the hardware or software that was used to play the game. In 


the case of Billy Mitchell's 1,050,200 and 1,047,200 direct feed submissions, evidence in this paper 
supports the claim that these tapes, which were historically used by Twin Galaxies to verify the scores and 
record them in the database as original unmodified arcade gameplay, are not from original unmodified 
arcade hardware. Additionally, based_on the refresh rate findings and correlation with specific MAME 
transitions, the gameplay can be pinpointed as being of MAME 0.115 or below’s source code, with the 


refresh rate set to 60.6 Hz or 99% CPU cheat setting. 


Throughout this paper, it is repeatedly stated that the tapes show MAME gameplay. However, one 
could argue that the tapes simply show emulator gameplay, but perhaps not a version of MAME. The 
reason MAME was given as the definite emulation platform in this paper is because during the creation of 
these tapes (2004-2007), there were no other developed emulators for arcade Donkey Kong [25]. 
Therefore, MAME was the only option for non-arcade hardware for playing Donkey Kong at that time. It 
is possible, however, that MAME source code was taken and repackaged as an entirely different emulator 
or system. Thus, the distinction is made that the tapes are specifically derived from MAME 0.115 or 
below’s source code. This includes devices like the 60-in-1 board that use MAME’s source code for 
emulation. 

The reason for the refresh rate being set to 60.6 Hz is left to speculation. One possible explanation 
is that whoever produced the tape wanted to ensure that the timing was accurate to that of arcade 
gameplay to avoid detection. MAME is known to run at a refresh rate of 60.60606 Hz. (MAMEdev, the 


development team behind MAME updates, made this same decision with 0.116u3.) However, this is 
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impossible to verify without the individuals involved in the production of these tapes explaining their 
motivations. 

Given that the irregularities in Mitchell’s tapes remained undetected from 2004 until 2018, one 
may ask why the supposed eyewitnesses to these games could not spot the problems in the gameplay. 
However, it should be remembered that these frames only last for one 60th of a second. Quite simply, the 
shortest interval of time humans can recognize is 13 ms [26] (which is very close to the 16.6 ms frame 
time), and the tapes were not publicly available until 2016 [27]. Additionally, the layman would not have 
the prerequisite knowledge to even know what MAME or arcade transitions look like. For these reasons, 
eyewitnesses are not a valid source of information to determine whether the output on the screen was 
from MAME or an arcade board. 

One real-world example of eyewitnesses being unreliable for spotting cheating is the case of Ben 
Johnson’s 100-meter dash in the 1988 Summer Olympics, for which he was temporarily awarded the gold 
medal [28]. Every person at the Olympics in Seoul, South Korea may have seen Johnson run the race, but 
it was impossible for the general public to know that he had used anabolic steroids prior to the event, 
which were detected in his blood. For the case of Donkey Kong scores, the transitions are equivalent to 
the drug test that stripped Johnson of his medals. 

Using the knowledge in this investigation, any future gameplay that is submitted under suspicious 
circumstances can be evaluated using the rationale in this document, and the adjudication body will be 


secure in the fact that their conclusion is backed by physical concepts. 


VII. Appendix 
Vila. Flipped Orientation Effects on the Transition 
As mentioned in section IIb on orientation, it is possible to flip the orientation of the video by 
hardware methods, relative to the default position, through changing the game to cocktail mode and 
playing the game in player two mode. When hardware register $7D82 is set to 1 from the DIP switches 


and player two mode is enabled, the video hardware reads the VRAM starting at the end and works its 
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way back to the beginning. This is like reading a book from the last page to the first, where the book is the 
VRAM contents. As a result, the contents are output upside down on the screen. However, as described in 
previous sections, the monitor always scans this reversed memory onto the screen in the same way that 
was shown in Figure 4. Thus, the transitions are affected by this change as the scanning direction and 
VRAM filling did not reverse together. 

Therefore, in Figure 24, the resulting first frame of the transition from a flipped orientation on 
arcade is seen next to the standard orientation transition. 


Frame 1, player 2 mode cocktail Frame 1, player 1 mode standard 
transition transition 
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Figure 24: Cocktail player 2 frame 1 transition (left) versus standard player I frame I transition (right). 
From this figure, these two transitions are completely different, ignoring the obvious extra player 
scores in the example on the left. Additionally, even if the orientation were changed through the failure or 


removal of a transistor in the video circuitry. The above transitions still do not look like the transitions in 


either of Billy Mitchell’s gameplay tapes. 


VIIb. Billy Mitchell 1,047,200 2006 MTV Announcement Video 


An MTV interview with former Twin Galaxies referee Robert Mruczek was conducted in 


February 2006 entitled "Smashing Apart the Donkey Kong World Record" [29]. This video shows a short 
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segment with Mruczek explaining the context of Billy Mitchell’s 1,047,200 tape submission while the 
tape plays in the background. This footage is significant in that it was recorded within a month after the 
score was verified on Twin Galaxies [30], thus, it is a good historical time capsule to rule out any changes 


to the tapes that may have occurred since 2006. In Figure 25, a frame from this footage is shown. 


Figure 25: Transition frame from the 2006 MTV snippet. 


As can be seen from the frame in Figure 25, the three-girder pattern common to MAME is still 
visible, as was shown in the direct feed tapes. Additionally, the orientation of the television is still 
abnormal from the expectations for arcade gameplay. This historical video is clear cut evidence that Billy 


Mitchell’s tapes have always shown MAME signatures in the transitions. 


VIIc. Rolling Shutter Effect 


This point where the end of the screen is reached is designated as the end of the frame, but it is 
possible to capture the sum of two frames together from the video hardware if the capture device is an 
external camera. This can create confusion in that it seems that the video hardware is inconsistent in the 
output of the transitions, but this is not due to the hardware itself. In Figure 26, an example of this 
composition occurs due to camera frame rate being out of sync with the video output seen, where the 


frame from Figure 8, and frames 1 and 2 from Figure 9 are all summed together. 


29 


200000 101100 


Figure 26: Frame rate inconsistency causing a variation in the video transition. 

Regardless, even in figure 26, three predicted frames can all be identified. Therefore, this output 
could still be properly verified as arcade hardware. This kind of behavior, known as the “rolling shutter” 
effect, is the result of the camera's shutter scanning across the sensor of the camera, which does not open 
and close instantaneously [31]. This can be a mechanical or electronic effect. More specifically, the 
camera sensor is being exposed to the light from multiple frames of video from the monitor at once. This 
behavior is not observed in direct capture games, only those captured with an external camera. For a 
direct capture game capture at 60 frames per second (FPS), the capture device locks onto vertical and 


horizontal sync pulses, so partial frames are not possible. 


VIId. High Speed Camera Recording of the Barrel Transition 


Using a high-speed camera running at 960 FPS, it is possible to record and verify the scanning 
mechanism that was described, and then modeled in Figure 15. Through this recording, the existence of 


the VRAM scanning mechanism was physically confirmed. In Figure 27, the result of recording the 
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transition at 960 FPS is seen, where the left screen is the default orientation, and the right screen is the 


player-two, cocktail orientation. 


Figure 27: The scanning of VRAM into the graphics on the screen, as shown on the monitor for standard 
orientation (left), and cocktail orientation (right). Recorded at 960 FPS. 
From Figure 27, the scanning bar is obviously larger than what is seen in animation in Figure 15. 
This is because the camera frame rate is not fast enough to capture a single scanline as it traverses the 
screen, so multiple scan lines of the electron beam are being integrated into the bright moving block when 
the camera shutter is open. To capture a single scan line beam of light, the camera would have to have a 
framerate of 16,000 FPS, which is the horizontal refresh rate of the monitor. 
Using the camera FPS and the number of horizontal lines, the thickness of the scanning bar can 
be calculated in terms of scanlines below. 
264 Lines / (960 Frames/second / 60.6060606 Hz) = ~16 scanlines 
The reason the screen is dark shortly after the beam scans an area is because the phosphor in the 
screen of the monitor does not stay lit up for a long period of time. That is why the frame must 
continuously be scanned fast enough that the darkening of the monitor due to the phosphor dimming is 


not noticeable to the human eye. Additionally, the reason the scanning bar in the figure on the right 
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appears to be scanning in the opposite direction is because the camera was flipped as well to compensate 
for the upside down video. In reality, both beams are scanning in the same direction, relative to the bottom 
of the monitor. 

This footage confirms the scanning behavior in Figure 15 is present on unmodified arcade 


hardware without question, as well as the transition variation from a flipped orientation. 


Vile. VGA to Composite to VCR Recording 


If Billy Mitchell’s scores were recorded on a computer, they had to be converted from 31 kHz, 
Video Graphics Array (VGA) video to 15 kHz, National Television System Committee (NTSC) video for 
recording on a VCR. This either happened within the computer, or externally using a converter. To verify 
this, MAME video from MAME 0.85 (which shows the same transitions as MAME 0.115) running at 


60.6 Hz was output to a VCR using the following setup in Figure 28. 


Figure 28: Setup for recording MAME gameplay to a VCR. 


Due to the frame rate discrepancies between the computer and the MAME output, there are often 
many transition frames that do not look exactly like those shown in Figure 20. In Figure 29, a comparison 
between a transition in Billy Mitchell’s 1,047,200 tape and a transition from the setup shown in Figure 28 


are shown below. 
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Figure 29: Transition frame from the setup shown in Figure 28 versus an abnormal transition frame from 
Billy Mitchells 1,047,200 tape. 

From this section, another feature of Mitchell’s tapes has been confirmed: they were recorded on 
a computer with significant tearing due to vertical sync (Vsync) issues. These abnormal transitions are 
due to screen tearing, which occurs due to a mismatch between the computer refresh rate and MAME’s 
refresh rate. Vsync settings correct for issues like this by having MAME wait until the monitor has 
completed its refresh cycle before updating its frame [32][33], however, MAME’s “-waitvsync” setting is 
disabled by default. Thus, the screen tearing manifests in the transition as multiple frames being 
combined, like what was seen from the rolling shutter example (Albeit for a much different reason). 

Additionally, th transition fram. ld never n on arcade direct fi i Figur 
29 is yet another fingerprint from Billy Mitchell’s tapes that prove they were not recorded on arcade 
hardware, but rather a computer running MAME. Screen tearing is an artifact that directly originates from 
refresh rate discrepancies between the monitor refresh rate and the game’s refresh rate. Thus, it cannot 
originate from unmodified Donkey Kong hardware because there is only a single vertical refresh rate 
present on Donkey Kong hardware, which is 60.60606 Hz. This finding proves unequivocally that Billy 


Mitchell’s tapes were recorded on MAME with significant Vsync issues. 
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VIIf. RGB to NTSC Converter Device 


When recording his tapes, it is claimed that Billy Mitchell utilized an RGB to NTSC converter 
designed in 1996 by a company called “Two-Bit Score”. This converter is shown below in Figure 30 on 
the left, with the receipt for the purchase on the right. The receipt and converter information was provided 


during the onset of the Billy Mitchell score dispute by Robert Childs. 


a 
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Figure 30: Two-Bit Score RGB to NTSC Video Converter (left), and the receipt (right). 

This device utilizes some passive components (like resistors and capacitors), a crystal oscillator, 
and an RGB to NTSC encoder IC. This IC is most likely an BH7236 or similar variant [34]. This 
conclusion is reached given that the chip seen in the photo has the same pin count as the BH7236, and 
pins 2, 3, and 4 all go to the RGB bypass capacitors (which is also seen in the application circuit for the 
BH7236). The exact IC cannot be verified because the information on top has been grinded off to 
obfuscate the functionality of the board. 

Mr. Video, which the writer of this paper designed, utilizes a similar IC for its operation (AD725) 


[35]. For all the direct feed arcade footage in this paper, Mr. Video was utilized for conversion of arcade 
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RGB video to NTSC video that can be easily captured using a capture device or VCR. An image of Mr. 


Video is shown below in Figure 31. 


E) MR.VIDEO. ¢ 
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Figure 31: Mr. Video RGB to NTSC Video Converter for Donkey Kong PCBs. 
In Figure 32, to prove similar functionality between these two ICs, block diagrams for the AD725 


and BH7236 are shown side-by-side from their respective datasheets. 
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Figure 32: Functional block diagram for the AD725 (left) versus BH7236 (right) ICs. 
Both of these ICs do not utilize any memory, which is needed for a framebuffer, to convert from 


RGB to NTSC video. At most, a framebuffer in the converter would cause vsync tearing similar to what 


was seen in section VIe, and not make the transitions look like MAME. This is because by the time the 


converter is receiving the frames, they have already been drawn by the arcade video hardware. Therefore, 


the frame buffer would only combine and distort existing arcade frames. A framebuffer of the VRAM on 
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the arcade hardware itself is necessary to show the transitions that are seen in Mitchell’s tapes. No amount 


of delay, latency, or loss will cause the transitions to change from those produced on an arcade machine to 


those produced on an emulator. 


For greater verification that the two-bit converter does not change the transitions in any way, the 
transitions produced from an experiment using the converter were examined. This test was completed by 
Chris Gleed in 2018 after being sent a two-bit converter by Twin Galaxies. Just as was claimed in Billy 
Mitchell’s tapes, Gleed uses the two-bit converter to convert arcade RGB video to composite video, and 
then this composite video is captured on a VCR. Finally, the VCR output is digitized using a USB capture 
device so it can be uploaded to Youtube. 

The walkthrough of this setup is seen in citation [36], the video recording is seen in citation [37], 
and the forum post where Gleed posted this experiment is seen in citation [38]. The two-bit converter that 
Mitchell claimed to use in his setup is seen in Gleed’s walkthrough. In Figure 33, the barrel transitions 
from Gleed’s recording are shown. 


Frame 1, VHS Tape, two-bit converter Frame 2, VHS Tape, two-bit converter Frame 3, VHS Tape, two-bit converter 
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Figure 33: Barrel transitions from Chris Gleed 5 Two-Bit converter VCR recording. 
As expected, the transitions from the Two-bit converter VCR output look exactly like the arcade 
transitions that have been demonstrated and analyzed throughout this entire paper. This is because the 


converter cannot replace the VRAM scanning method with the framebuffer “snapshot” behavior that is 


seen in MAME. This analysis further proves that no element in Billy Mitchell’s claimed setup could have 


produced MAME transitions. 
36 


VIII. References 


[1] Trachtman, Paul (September 1981)._"A_ generation meets computers on the playing fields of Atari". 
Smithsonian. pp. 50-53 [52]. Archived from the original on March 19, 2006. 


[2] "Players Guide To Electronic Science Fiction Games". Electronic Games. 1 (2): 35—45 [36]. March 
1982. 


ee ee TN 195740/http://gamers.guinnessworldrecords.com/aboutus/twin_gal 
axies.aspx 

[4] https://www.insiderintelligence.com/insights/esports-ecosystem-market-report/ 

[5] https://donkeykongforum.net/index.php?topic=366.0 

[6] https://web.archive.org/web/19991006214540/http://twingalaxies.com/Rules1.html 


[7] https://(www.mamedev.org/history.html 


[8] https://www.twingalaxies.com/game/donkey-kong-us-set-1/mame 


[9] https://github.com/mahlemiut/wolfmame 


[11] 
https://web.archive.org/web/20171116213101/https://www.twingalaxies.com/showthread.php/168098-Twi 
n-Galaxies-Donkey-Kong-(Arcade)-Recording-Rules 


https: archiv 
gi=3852&vi=22 


[13] T. Iki, "CRT Display," [1989] Proceedings. The First International Conference on Image 
Management and Communication in Patient Care: Implementation and Impact, 1989, pp. 232-236, doi: 
10.1109/IMAC. 1989.693757. 


[14] https://junkerhq.net/xrgb/index.php/Optimal timings 
[15] https://donkeykongforum.net/index.php?topic=2761.msg42026 


[16] https://youtu.be/3 BJU2drrtCM?t=191 
37 


[17] https://www.mamedev.org/releases/whatsnew_0196.txt 


[18] 
http://www.arcaderestoration.com/printgamedips/2477/Donkey+Kong+US+set+2/Donkey+Kong.aspx 


[19] https://www.arcade-museum.com/manuals-videogames/D/dkong1.pdf 

[20] https://github.com/furrykef/dkdasm/blob/master/dkong.asm 

[21] https://www.arcade-museum.com/manuals-monitors/sanyo-ezv 1 9raster.pdf 

[22] https://undumped.miraheze.org/wiki/List_of Undocumented Discrete Logic Arcade Games 
[23] https://github.com/mamedev/historic-mame/releases/tag/mame0115 


[24] https://www.mameworld.info/mameinfo/download/NEWS.txt 


[25] https://web.archive.org/web/20071004091553/https://www.emulator-zone.com/doc.php/arcade/ 


[26] https://mollylab-1.mit.edu/sites/default/files/documents/FastDetect2014withFigures.pdf 


[27] https://www.youtube.com/watch?v=K YtJzRevOzk 


[32] https://www.displayninja.com/what-is-screen-tearing/ 


[33] https://docs.mamedev.org/commandline/commandline-all. html 
[34] https://pdf.dzsc.com/BH7/BH7236.pdf 
[35] https://www.analog.com/media/en/technical-documentation/data-sheets/AD725.pdf 


[36] https://www.youtube.com/watch?v=VfnHXjrm2¢8 


38 


[37] https://www.youtube.com/watch?v=rCtPb2-iV Vs 


[38] 
https://www.twingalaxies.com/showthread.ph 


ints-Hammer-A llowed-Plaver-Billy-L-Mitchell-Score-1-062-800? 
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IX. About the author 


Email: tfokkens@protonmail.com 

I am a hardware engineer working out of San Jose, California. I received my bachelor’s degree in 
electrical engineering from Missouri University of Science and Technology (MST) in May 2021, and I 
will receive my master’s degree in December 2022. My background and research are in electromagnetic 
compatibility (EMC), intentional electromagnetic interference (I-EMI), power and signal integrity (SI/PI), 
and high speed digital systems. 

My experience with the competitive Donkey Kong scene began when I joined the Donkey Kong 
Forum in 2014. From there, I improved my skills through the help of the community and became the 
youngest person to “kill screen” arcade Donkey Kong at the age of 16, in January 2015. In October 2015, 
I achieved the world record on the “hard ROMs” version of Donkey Kong (as seen in Guinness Book of 
World Record Gamer’s Edition, 2017). In November 2015, I achieved 1 million points in the standard 
version of Donkey Kong. In early 2019, I founded Snektronix Incorporated with the help of two other 
community members, where we designed the Donkey Kong direct capture device called Mr. Video. These 
devices are available at Facebook.com/snektronix. In July 2019, I achieved 1,116,400 points on Donkey 
Kong, which put me at #10 on the arcade leaderboard on Donkey Kong Forum at the time. 

My involvement in the Billy Mitchell dispute began in January 2016, when I uploaded the tape 
recordings that were later used for the initial analysis of the transitions. Since then, I have collaborated 
with individuals to compile technical evidence regarding Donkey Kong transitions to understand the 
differences between Arcade and MAME video. 

Given my own personal love for this community and how many opportunities it has afforded me, 
I wrote this document independently in hopes that the drama and vitriol associated with the Billy Mitchell 
dispute can be put to rest in the court of public opinion. Additionally, the cross section of arcade gaming 


and electrical engineering was seminal to my early foundations as an electrical engineer. 
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X. Expert Verification and Peer Review 


Various experts in classic arcade gaming, video game development, emulation, and hardware 
engineering were contacted to verify that the contents of this paper are credible and accurate. This is an 
informal version of peer review that would occur when a scientific paper is submitted to a journal for 
publication. All the expert verification statements that were obtained at the time of publication for this 
version of the paper are shown on the subsequent pages. These statements are also available at this 
document’s origin in PDF form. All formatting and font sizes that were chosen by each expert was left the 
same to avoid editing any part of their statement. 

Any person who has appropriate credentials who would like to provide their own verification of 
the contents of this paper can contact the author at tfokkens@protonmail.com. Additionally, any errors or 


suggested changes are welcomed to further improve this document. 
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Xa. John Kowalski Expert Verification Statement 


My name is John Kowalski. | have been programming software since the 1980s and 
have worked in the video game industry for over a dozen years. | have worked on 
numerous published console and arcade game compilations for companies such as 
Atari, Midway, Sega and Williams. These classic arcade game compilations involved 
reverse engineering the original arcade hardware and software then creating 
emulations of the original hardware and software function on different hardware. 


In 2007, | reverse engineered arcade Donkey Kong and created a Donkey Kong 
emulator for the Tandy Color Computer 3. In 2015, | revisited the project and 
expanded upon it by adding new stages and new game mechanics to the game. The 
resulting Donkey Kong Remix was first created for the Tandy Color Computer 3 and 
then also for original arcade hardware in the form of a hardware kit that can be 
plugged into original Donkey Kong arcade cabinets. 


Since then | have also created Donkey Kong Trainer (which can be used by Donkey 
Kong competitors to help improve their game play) and also reverse engineered 
Donkey Kong Junior and created Donkey Kong Junior Remix. | was also part of the 
team that created Mr. Video, the direct-feed video capture solution for Donkey Kong 
arcade cabinets. 


| have years of expertise and extensive knowledge of both Donkey Kong’s hardware 
and software and also of emulators such as MAME and video generation hardware in 
general. 


| have read Mr. Fokkens’ paper and confirm that the technical information within is 
accurate and correct. | agree with the results and findings presented in his paper. 


Signed on August 19", 2022 


John Kowalski 


https://www.dkremix.com/ 
https://www.mobygames.com/developer/sheet/view/developerld,43170/ 
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Xb. Barry Rodewald Expert Verification Statement 


| am Barry Rodewald. | am a member of MAMEdev and am maintainer of WolfMAME. | 
occasionally submitted code to MAME and it’s then sister project MESS, until joining MESSdev (and 
eventually MAMEdev) around 2006. 


| have developed arcade emulators since the late 90's, in particular GalEMU (Galaxian hardware 
emulator) and QPlayer (Capcom QSound audio emulator). 


Also, |amaneditoratthe MAME Action Replay Page (MARP), havingjoinedthesiteinlate 1998 and 
maintain our INP analysistools. 


| have read Mr. Fokkens’ paper, and find the information in it accurate and well-detailed. | agree with 
its findings. 


01/09/2022 


Xx Bory Redden ald 
~ Barry Rodewad  s—=~CSsti‘sS 


Signed by: Barry Rodewald <mahlemiut75@g 


https://github.com/mahlemiut/ 
http://replay.marpirc.net 
http://galemu.emuunlim.com/ 


43 


Xc. Jeremy Young Expert Verification Statement 


My name is Jeremy Young. I am a Donkey Kong killscreener and top 10 player in Pac-Man 
Championship Edition DX+. I am the high score moderator at Donkey Kong Forum (DKF), a 
role I have served in for almost nine years. Since March 2022 I have also been the forum's 
administrator. 


In August 2017 I submitted a dispute to Twin Galaxies in regards to Billy Mitchell's claimed 
Donkey Kong arcade score of 1,062,800. The basis for this original dispute was that the only 
live, on-location video footage available of the claimed achievement showed a Donkey Kong Jr. 
PCB being used as a stand-in for a Donkey Kong PCB. 


Subsequent analysis of the claimed direct feed recordings of Mitchell's arcade scores of 
1,047,200, 1,050,200, and 1,062,800 revealed indisputable evidence that these recordings were 
produced with an emulator. Accordingly, in February 2018, I updated the Twin Galaxies dispute. 
In my role as high score moderator, I also removed Mitchell's 1,062,800 score from the DKF 
High Score List at the same time. Twin Galaxies found the evidence and dispute credible and 
removed all of Mitchell's scores from their database in April 2018. 


Over the following two years, Mitchell filed various frivolous lawsuits, including one in 
February 2020 against myself, Jeff Harrist (founder and former administrator of DKF, now 
deceased), and DKF itself. Mitchell voluntarily dismissed that lawsuit in January 2022. 


In the early days of the dispute, when explanations, clarifications, and rebuttals were most 
needed, Tanner Fokkens' technical expertise was invaluable to the classic arcade and high score 
community. It remains so to this day. Fokkens' work has not only helped educate the masses on 
the finer details of arcade hardware, it has also helped reinforce the integrity of video game high 
score competition. 


Fokkens' paper is a great introduction to many of the complex issues surrounding Donkey Kong 
arcade hardware and emulation and is accessible to beginners and experts alike. I support his 


work and the conclusions therein. 


Signed this date, August 22, 2022. 


J ereny Young 
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Xd. David Race Expert Verification Statement 


My name is David Race. | am the current world 
record holder on the original arcade classic Pac- 
Man. 


For more than a year and a half, from February 
2018 to September 2019, | sought to defend 
Billy Mitchell to one degree or another, going as 
far as testing the hardware Mr. Mitchell claimed 
was used for two of his disputed Donkey Kong 
scores. 


| submitted an Initial Assessment to Jerry 
Byrum, of the International Video Game Hall of 
Fame, in September 2018 where | concluded 
that Mitchell's disputed games were not 
produced in the way that was claimed for them. 


After Mr. Mitchell threatened litigation against 
Twin Galaxies and Guinness World Records in 
September of 2019, | became aware of Billy 
Mitchell's Evidence package, which | discovered 


contained numerous provable lies and false 
statements provided in affidavits signed by 
supporters of Mr. Mitchell. 


Around the same time | came across new 
evidence which completely debunked what | had 
offered in defense of Mitchell. | also became 
painfully aware that Mr. Mitchell had 
manipulated and used me in the service of a 
false narrative. 


| continued to learn more about how the original 
Donkey Kong hardware worked and began to 
contrast that with alternative and more modern 
hardware. 


In September of 2020, | offered a declaration in 
support of Twin Galaxies in the defamation case 
Mitchell had brought against them. The 
following month, | was also asked to provide 
responses to Mr. Mitchell and his son, who filed 
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false allegations against me in answer to my 
earlier declaration. 


Earlier this year in March(2022), | came across 
some info | had either dismissed or 
misunderstood during the time | was seeking to 
clear Mitchell's name, where | finally understood 
the video and monitor processes involved with 
the output of original Donkey Kong hardware, 
where such could NEVER produce what is found 
on Mitchell's disputed recordings. 


Much of this information has been developed 
and expanded upon in the paper presented by 
Mr. Fokkens, to whom | wish to express my 
sincerest gratitude. | have been helped by him 
over the past few years in understanding certain 
technical details that no one else was either able 
to explain, or willing to do so. 


| have recently tested some of the things 
covered in his paper, and received real world 
confirmation of how both arcade and MAME 
produce their respective outputs. 


|, therefore, believe the results and conclusion of 
Mr. Fokkens' presentation are unimpeachable. 


His work has my full support. 


Thank you. 


Signed this date, 08/18/2022 @ 7:00PM Eastern, 
in Dayton, Ohio 45414 


David W. Race 
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Xe. Wes Copeland Expert Verification Statement 


My name is Wes Copeland. | am the former world record holder on Nintendo’s 
original arcade title, Donkey Kong. | have broken the high score record four times. 


During my world record pursuit, | took an interest in the game's previous record 
holders. | was sure | could learn something from each of their approaches to the 
game as | crafted my own winning playstyle. 


Around 2014, | first heard from another high-level contender that it was an open 
secret in the community that Billy Mitchell’s play was likely done under dubious 
circumstances. | strived to study whatever footage of Mitchell's world record 
games | could obtain. 


| didn’t make much progress on this matter until around or about early 2016 when 
footage of Mitchell’s performances was digitized from VHS and uploaded online. 
Unfortunately, upon studying the gameplay in the tapes, | found Mitchell’s reckless 
scoring techniques too impractical to apply, to put it kindly. 


At this point, | was sure that Mitchell's record performances were illegitimate, and 
there was indeed circumstantial evidence to support this. However, a smoking gun 
did not emerge until the discovery of MAME transitions in Mitchell's digitized 
tapes. 


Being one of the very few players at the time to have a homemade “direct feed” 
setup, | attempted to reproduce the transitions with original arcade hardware. | 
was unable to do so. 


On March 13, 2018, | posted a $1,000 bounty online for anyone to claim if they 
could provide a reproduction of the transitions seen in Mitchell's footage from 
original arcade hardware. Over four years later, the bounty remains unclaimed. 
The explanations and conclusions drawn in Tanner Fokkens’ paper demonstrate 
why | believe that bounty will remain unclaimed. 


Mf Cre avo 


Wes Copeland Sep 5 2022 
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Xf. Carlos Pineiro Expert Verification Statement 


My name is Carlos Pineiro. | have been working with Tech for almost 40 years, holding degrees in 
Electrical Engineering and Technology. | started very young by writing programs for fun, then moved up 
late 80s to late 90s repairing pagers and cell phones at my father’s beeper store. Graduating from 
Engineering school in 1999, | went to work for a company reverse engineering the lock-out region chip 
on DVD players to allow units to place discs from ALL parts of the world. Next, | went to work at a new 
big box arcade company owned by Sega of America and a movie studio partnership. My job was to keep 
the machines in working order (including pinball repair), make repair reports for manufacturers, and 
work on game circuit boards. At the venue we had a uniform standard game cabinet we used for the 
“Classic” games. My task was to create circuits that allowed these old games to work with these 
cabinets, e.g., converting Space invaders Black / White output circuit to work on color monitor and 
board level repairs. During my time there | collected many great arcade boards. 


| left Sega in late 2001. Fast forward about 15 years and | still had a large collection of game boards in 
my storage. | collected them way back then dreaming that one day | would open my own arcade. | 
figured | was never going to do it anymore since, with the quality of home consoles, it wasn’t a good biz 
anymore. | didn’t just want to trash these boards, so | searched for local arcade repair shops and 
discovered Mr. Robert Childs’ “Arcade Game Sales” Shop. Went over and offered Mr. Childs a deal to by 
all my boards that were going to be trashed. He bought them. His repair shop was FANSTATIC! It 
brought back a lot of memories. We spoke for a bit about arcades and repairs. So, | found him and his 
shop on Facebook, added them on to my profile. 


About 2 years later | see a post by Mr. Childs about an RGB to Composite Video convertor used for 
disputed games by Billy Mitchell. The post was long, but the tech part was sound. Working on making 
circuits for classic games boards at the Sega venue, | offered my take on the post. Next morning my 
reply had many comments and even requested by people to make contact. Called some back and went 
to Arcade games sales and | offered to help with investigation. This is where | was introduced to Billy 
Mitchell. And | started to work. After weeks of testing on and on and on, | finally found patterns which 
could not be created by the claimed machine boards used by Billy. And | was able to produce the look 
using a MAME setup | made in my home. | wrote my final conclusion which was that the games on 
Billy’s tapes could NOT have been produced by a genuine unmodified Donkey Kong board. 


| have read Tanner Fokkens’ report, and | fully endorse that all technical data is accurate and well- 
presented for the non-Technical to understand. It covers the hard technical subjects well. 


C7EL— V2 022 


Carlos Pineiro, Miami,FL 


cashe@CARLOSystems 
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